No, we can't make changes now. That was discussed before anyway. With the current physics, the road cars can roll with slicks so it's not as good as you might think. We don't want to add things to the demo. Demo is supposed to be a demonstration of LFS, so people can buy a license if they like it. We have bills to pay.
This morning I could fix a serious bug if anyone finds one but other than that I won't be making any changes.
This morning I could fix a serious bug if anyone finds one but other than that I won't be making any changes.
Thanks for the test.
Yes, the IS_RES TTime in practice mode is the time since the start of the session until... and here is the dirty secret... the time the packet is processed at the server (a short and unpredictable time after the packet is sent - in this case 0.47 seconds). And, as you said, the IS_LAP ETime is the time since the lights go green (3 seconds after the start of the session) until the time the car crossed the finish line. So that's how to get the 3.47 seconds difference.
Explanation: The IS_LAP is triggered by an internal packet that has a proper time stamp (from the driver's computer) of total time as that is very important for accuracy. But the internal result packet that triggers the IS_RES packet in qualifying mode doesn't have that accurate time stamp as it was never needed before. So the server goes with the time the packet is processed for this new use of TTime in IS_RES in qualifying. I think for the purposes you are describing, that additional slight delay won't be a problem. I think it could only be a problem if two qualifiers cross the finish line at almost exactly the same time, with exactly the same lap time, then the tie-break between these two identical laps might not get the right order. But that might never happen!
And if it did happen I think that would match the order generated by LFS...EDIT: Sorry, this isn't quite right as they are both triggered by the same internal packet. So I think it would be possible to make the IS_RES TTime in qualifying equal to the associated IS_LAP ETime if needed, by passing some extra parameters to a couple of functions. But then the order might not match the order generated by LFS in that very rare case described.
I always knew the steering wheel turns in LFS were too low, compared with real road cars. I had already changed most of the road cars in the development version to the new value. It is an old request to update the steering angles, maybe ever since the higher range controller wheels were available. So now as I was dealing with wheel turns on the racing cars I started to look into steering ratios.
Side note for anyone who doesn't know: steering ratio is the degrees turned by the steering wheel, compared with the degrees turned by the front wheels. https://en.wikipedia.org/wiki/Steering_ratio
Normally in road cars this is between around 12:1 and 18:1 - usually closer to around 15:1 - but in LFS previous versions:
- FWD road cars had a ratio of 12:1 (720 deg steering wheel for 60 deg road wheel)
- RWD road cars had a ratio of 10:1 (720 deg steering wheel for 72 deg road wheel)
So the previous version of LFS was outside of the values ever seen in real road cars. With the new adjustment, the FWD cars have a ratio of 900:60 which is 15:1 and the RWD have a ratio of 900:72 which is 12.5:1 and this is closer to reality (though still a bit low in the RWD case).
I know this will make the cars feel different, while having the same underlying physics, but I'm hoping that as it's closer to reality that shouldn't be a bad thing.
EDIT: This change should not affect mouse or keyboard users at all. In their case the keyboard or mouse operates the steering directly so there is only a graphical change. The change in feeling should only affect wheel users and maybe has a slight affect on joystick users.
Thanks for the detailed descriptions.
Some of them I won't worry about but I will have a look to see if some of them can be corrected easily.
Last edited by Scawen, .
It is CPU, not GPU, time which is being measured. Actually it's just time itself between one point and another.
The "Draw" section is supposed to represent the time taken for the CPU to work out everything related to drawing the shadows, environment maps, mirrors, main views, etc. During this time there are a lot of calculations and thousands of calls to D3D to set constants, set active textures, set vertex and index buffers, and request sections of those buffers to be drawn. Even some vertices and triangles to be sent to the GPU every frame (for flexible objects like drivers and tyres). There is a *lot* of work for the CPU to do when drawing.
That is why it can help to separate physics and rendering onto separate threads. The GPU doesn't just magically know what do to, it is instructed by thousands of calls every frame, from the CPU, through Direct3D. If the CPU didn't have to do much then there would be no need for a separate thread for rendering.
However, there is something seemingly anomalous about a high value in "Draw" in certain situations. In my case I can make Draw go over 90% by selecting exclusive mode full screen (SHIFT+F10) with Vertical Sync enabled. I don't know exactly why that is without looking into it, but it seems quite certain that the time while we are waiting for the vertical sync, is within the start and end of the section I have marked as "Draw". It's nothing to worry about.
If I go full screen in borderless window mode (SHIFT+F11) then the waiting time is in "Flip" which I would have expected to be the case in exclusive mode full screen too. So that's the only anomaly but I'm not really too worried about it.
Without vertical sync enabled, but frame rate limited, the spare time moves into "Sleep" so we get a much better reading for how long the Draw is taking. If you disable frame rate limitation then frame rate goes insane and Draw goes up to a high number. That is expected as we are asking LFS to draw as many frames as possible with every scrap of time remaining.
That is only a waste of energy. Frame rate should either be limited to a set value or vertical sync should be used. There is no point in extremely high frame rates, specially since the new test patches have sorted out a controller issue that previously caused high frame rates to be useful for force feedback.
I repeat - that is no longer the case. Please save some energy and heat by limiting frame rate (e.g. 100 fps) or using vertical sync if you prefer.
The "Draw" section is supposed to represent the time taken for the CPU to work out everything related to drawing the shadows, environment maps, mirrors, main views, etc. During this time there are a lot of calculations and thousands of calls to D3D to set constants, set active textures, set vertex and index buffers, and request sections of those buffers to be drawn. Even some vertices and triangles to be sent to the GPU every frame (for flexible objects like drivers and tyres). There is a *lot* of work for the CPU to do when drawing.
That is why it can help to separate physics and rendering onto separate threads. The GPU doesn't just magically know what do to, it is instructed by thousands of calls every frame, from the CPU, through Direct3D. If the CPU didn't have to do much then there would be no need for a separate thread for rendering.
However, there is something seemingly anomalous about a high value in "Draw" in certain situations. In my case I can make Draw go over 90% by selecting exclusive mode full screen (SHIFT+F10) with Vertical Sync enabled. I don't know exactly why that is without looking into it, but it seems quite certain that the time while we are waiting for the vertical sync, is within the start and end of the section I have marked as "Draw". It's nothing to worry about.
If I go full screen in borderless window mode (SHIFT+F11) then the waiting time is in "Flip" which I would have expected to be the case in exclusive mode full screen too. So that's the only anomaly but I'm not really too worried about it.
Without vertical sync enabled, but frame rate limited, the spare time moves into "Sleep" so we get a much better reading for how long the Draw is taking. If you disable frame rate limitation then frame rate goes insane and Draw goes up to a high number. That is expected as we are asking LFS to draw as many frames as possible with every scrap of time remaining.
That is only a waste of energy. Frame rate should either be limited to a set value or vertical sync should be used. There is no point in extremely high frame rates, specially since the new test patches have sorted out a controller issue that previously caused high frame rates to be useful for force feedback.
I repeat - that is no longer the case. Please save some energy and heat by limiting frame rate (e.g. 100 fps) or using vertical sync if you prefer.
Last edited by Scawen, .
It does seem reasonable except that I think implementing a rate limit would invalidate nearly all existing hotlaps. I don't think that's really worth it at the moment when physics are still compatible. I realise some people would disagree with that.
Probably is enough but there is one valid point to make. The Formula D limit for 2400 kg cars is 245mm.
So I have just decided to allow it up to 8 notches. Then at least the XR can have tyres down to 245 to comply with Formula D rules. Maybe no-one will use it but at least there can be no cause for complaint.
The FZR also gets the same 8 notches at the moment.
The FZR starting point in alternative config is 295 front and 355 rear. Going down 80mm from there results in a minimum width of of 215 front and 275 rear (front and rear are separately adjustable). This doesn't comply with Formula D rules. I'm guessing that isn't a problem, but do let me know if it would be worth allowing the FZR to go all the way down to 245.
Yes, I'll add a tyre width field in the IS_NPL packet.
Last edited by Scawen, .
In this case I was referring to the XRR vs FZR for hard track racing (not drift).
There is very little logic to trying make an ideal drift car with flawed tyre physics, based on a racing car with very few changes. It's not going to happen. But given that I'm only prepared to make one config (in this so-called minor update patch) there is some importance in making the XRR work well against the FZR for hard track racing.
That's why I'm waiting to hear from more people including some hard track hotlap or race results. I have to hear from more people.
I very much hope that I do not need to make another change. I want to release this update and get back to the development version.
I'm pretty sure drifting is too easy in LFS compared with real life. It's fun but the truth is it's easier than the real thing.
But 10mm less tyre width doesn't stop that being the case. Anyway I've said all I can say now.
EDIT: I hope to get it closer to the real thing in the new tyre physics. Actually in my current version of development tyre physics I think drifting is too hard compared with reality. But I'll be doing a lot of analysis to try to get things right.
I think the ideal thing would be if I could get this patch finished and get back to the development version where there is tyre physics to work on.
It's not possible to make a perfect drift car by changing a few values on a racing car in a flawed tyre physics model. It's not going to happen, because impossible things can't happen.
I don't think there's too much point arguing about 10mm which makes such a tiny difference. I believe people were saying (as I found myself) that the FZR was faster than the XRR. I hoped to improve that with this update, by making such a tiny change to the XRR's tyre width, doing the same at front and rear so as not to affect the car's balance.
I am aware that both of these cars have illegal rear tyre width compared with Formula D. But they aren't purpose built drift cars. This is an update to allow people to drift our racing cars, as requested.
But I described this all in a previous post so why am I going through it again?
It's not possible to make a perfect drift car by changing a few values on a racing car in a flawed tyre physics model. It's not going to happen, because impossible things can't happen.
I don't think there's too much point arguing about 10mm which makes such a tiny difference. I believe people were saying (as I found myself) that the FZR was faster than the XRR. I hoped to improve that with this update, by making such a tiny change to the XRR's tyre width, doing the same at front and rear so as not to affect the car's balance.
I am aware that both of these cars have illegal rear tyre width compared with Formula D. But they aren't purpose built drift cars. This is an update to allow people to drift our racing cars, as requested.
But I described this all in a previous post so why am I going through it again?
Thanks for the feedback.
I have come up with one small change to try but I'm not prepared to spend time trying to make a proper drift config. There is no possible way that could be 'right' with the existing tyre physics and no possibility of even using a vehicle editor. I've just about reached the end of what I can do for this update.
Remember these incompatible changes were meant to allow some more fun for drifters and other racers. There was no intention to try and create a proper drift car.
The only thing I can really do at this time is try to adjust the existing config in such a way that it tries to keep everyone a little bit happier than they would have been, but obviously not as happy as they could be if they had a real vehicle editor with hundreds of adjustments. I would still like that to be the case one day. But the only way to move in that direction is if I get back to the development version.
There are way too many changes that would be needed to make a proper drift car and I don't even think I am the one to do it. It would be a big project. Actually I propose to remove the "DRIFT / RX" name and go for "ALTERNATE" instead. No real point selling it as a drift car, because is hasn't been properly developed for that. It has just had a few changes that make drifting and rallycross possible.
So for now the suggestion I have is to simply increase the XRR front and rear tyres by 10mm each. This makes the car fractionally faster and more competitive with the FZR. I've tested it and to me the balance feels OK and I managed to lap 6 tenths faster than the other day. I won't change the spacing. So the outer edge of the wheels are 5mm further out.
Thanks for the feedback. I've now released another incompatible version. I've tried to sort out the most important issues and also tried to improve the balance of the GTR cars with the new configurations as a hard track racing category.
I can't change tyre physics or the properties of layout objects in this update. Those are more serious physics changes and I can't put time into that now as the development version is too different.
This update is intended to give more variety in drifting, hard track racing and rallycross. I'd be interested to hear from some better sim racers than me (that's most of you) how lap times compare with the GTR cars and how well the tyres work in the new configurations.
Changes in 0.6U19 (NEW INCOMPATIBLE VERSION)
Maximum number of layout objects increased to 2400
XR GTR in DRIFT / RX config has H-pattern shifter
Handbrake strength is now separately adjustable
10mm narrower rear tyres in XR GTR new config
10mm narrower F/R tyres in FXO GTR new config
10mm narrower track width FZ50 GTR new config
Tyre size displayed in Tyres tab in Garage
FIX: InSim IS_NPL did not report Config
https://www.lfs.net/forum/thread/95016
I can't change tyre physics or the properties of layout objects in this update. Those are more serious physics changes and I can't put time into that now as the development version is too different.
This update is intended to give more variety in drifting, hard track racing and rallycross. I'd be interested to hear from some better sim racers than me (that's most of you) how lap times compare with the GTR cars and how well the tyres work in the new configurations.
Changes in 0.6U19 (NEW INCOMPATIBLE VERSION)
Maximum number of layout objects increased to 2400
XR GTR in DRIFT / RX config has H-pattern shifter
Handbrake strength is now separately adjustable
10mm narrower rear tyres in XR GTR new config
10mm narrower F/R tyres in FXO GTR new config
10mm narrower track width FZ50 GTR new config
Tyre size displayed in Tyres tab in Garage
FIX: InSim IS_NPL did not report Config
https://www.lfs.net/forum/thread/95016
Last edited by Scawen, .
Test Patch U25: Multiplayer Updates
WARNING: THIS IS A TEST
THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM
PLEASE TEST BEFORE YOU POST
THIS PATCH IS NOT COMPATIBLE WITH VERSION U
Hello Racers,
Here is a new test patch: 0.6U25
The changes are listed below.
0.6U25 is NOT COMPATIBLE with 0.6U
- You can NOT connect online with 0.6U
- You CAN play replays from 0.6U
Please back up or rename your LFS.exe from version U so you can revert to it if necessary.
Changes from 0.6U23 to 0.6U25: COMPATIBLE WITH U23
Steering:
Road cars now have 900 degrees steering range with default setup
XF and UF GTR have 540 degrees steering range with default setup
Updated and fixed steering animations to cover new steering range
Removed option "Move view with animation" which had little effect
FIX for new bug: Steering wheel could turn too far with some setups
FIX for new bug: Switching setups while driver visible could crash
Training:
FIX: AI changed to low fuel load if overtaking lesson restarted
FIX: AI skill / admin commands no longer processed during training
FIX: Training lesson did not end if replay saving was interrupted
FIX: Refuelling depended on refuelling allowed in single player
FIX: Logo was visible under title during lesson replay
Misc:
Removed debug message "Replay name : temp_mpr"
Saving replay name now shown beside option in Options - Game
Blocked messages remain blocked when returning from game to lobby
Command /block [0/1/2] : block user messages (like the minus key)
InSim:
IS_RES: TTime in qualifying now indicates time in session
IS_RES: PLID is now zero if the player has left the race
OutSim:
OutSim packet is documented in docs\OutSimPack.txt
Added steering torque as additional field in new OutSim
All data options can be switched on with OutSim Opts 1ff
Translations:
More updated translations. Thank you very much, translators.
Changes from 0.6U16 to 0.6U23: NEW INCOMPATIBLE VERSION
Multiplayer prediction:
Position packet now includes contact patch offset for each tyre
Wear and temperature packet is more frequent and more accurate
Pit stops:
Command /canrefuel (no/yes) to set refuelling allowed in pit stops
Damage repair not required when changing tyre pressure or compound
New ALTERNATE setup configuration for the five GTR cars:
Selecting the new config in XRR/FZR/FXR decreases tyre width a bit
With alternate config, narrower tyres may be selected (adds offset)
Also ROAD_SUPER, ROAD_NORMAL, HYBRID, KNOBBLY tyres may be selected
High "Maximum Lock" is possible in XRR/FZR with narrower wheels
XR GTR in ALTERNATE config has H-pattern shifter
Tyre choices and steering lock:
XFR and UFR maximum steering lock increased to 30 degrees
LX4 and LX6 maximum steering lock increased to 45 degrees
Single seater racing cars can now use ROAD_SUPER tyres
Steering wheel turn amount changes with maximum lock
New handling for 'CAR.lfs' and 'shift_type.lfs' scripts:
LFS runs 'road.lfs' / 'sequential.lfs' / 'paddle.lfs' directly
(previously these scripts were called from a CAR.lfs script)
This is done after loading a car and immediately before CAR.lfs
Commands to run these scripts from another script are ignored
Controls:
Handbrake strength is now separately adjustable
Graphics:
Avoid upward lighting related to ground colour in internal views
InSim:
Config byte added to IS_NPL packet indicates setup configuration
IS_CPP Pos is now relative to "Centre view" not the user setting
IS_NPL RWAdj / FWAdj indicate rear / front tyre width reduction
New bytes set if /showfuel=yes: IS_NPL Fuel / IS_PIT FuelAdd
IS_SPX and IS_LAP new byte Fuel200 indicates fuel remaining
Interface:
Tyre size displayed in Tyres tab in Garage
Brakes / TC tab in garage separated into two columns (e.g. FZ50)
FIX: Heat in garage car's tyres was not updated when tyre changed
Virtual steering gauge hidden if live settings or pit instructions
New fuel options can be filtered and are visible on selected host
When alternative config is selected F12 display shows tyre size
/press and /shift commands now support 'minus' as parameter
minus key (block messages) now works in free view mode
Misc:
Maximum number of layout objects increased to 2400
You can now add up to 32 local drivers (real + ai) in multiplayer
Restored code preventing 2 cars joining autocross within 3 seconds
FIX: Wrong warning "Road tyres on rallycross track" in hotlapping
Translation update for help.txt:
host_cars - max is now 32
guest_cars - max is now 32
max_packs - max is now 12
mip_bias - default settings now -0.5 / -1.0 / -1.5 / -2.0
Translations:
Many updated translations. Thank you, translators.
Changes from 0.6U to 0.6U16: FINAL VERSION COMPATIBLE WITH 0.6U
Interface:
Pit speed limit is shown when car speed is below 2/3 of limit
Yellow and blue flags now alternate with RCM or penalty message
Prevented auto-repeat on block message and light switching keys
Command /spectv no - prevent selecting TV camera on spectate
Momentary flick to rear view after SHIFT+R is now avoided
Avoided downshift after pressing SHIFT+X to exit free view
In fact any 'key held' function after SHIFT+key is prevented
F12 pit instructions:
Pressure change with new tyre no longer counts as SETUP CHANGES
A new 'cancel' option beside the 'setup changes requested' line
Settings that will be adjusted are now shown in light red colour
FIX: rear tyre pressure was limited by front tyre pressure limits
FIX: symmetric pressure/camber request remained after pit stop
Multiplayer:
Maximum packets per second (/pps) has been increased to 12
Rolling resistance included in catch-up phase of prediction
Reduced steering glitch each time a position packet is received
Position packets are sent more frequently in response to steering
Command /showfuel (no/yes) allows remote car fuel load to be seen
More accurate transmission of fuel load from local to remote car
Most admin commands with parameter omitted report current value
Easier to set up LAN race: local IP address is shown on host screen
You can enter the local network computer name instead of IP address
FIX: Remote cars with worn tread could wrongly get a puncture
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Stop-go penalty caused car to get stuck in custom pit stop
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin
InSim:
IS_CPP FOV can now be used in-car but not smoothed (0 = no change)
InSim NLP / MCI minimum time interval reduced to 10 ms (was 40 ms)
FIX: It was possible to miss IS_PSF packet after taking over car
FIX: STime in IS_PSF packet was wrong after car was taken over
FIX: Free view roll is now reported in InSim IS_CPP packet
CPU usage display:
In Graphics or Misc options (in-game) click car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set
Support for live multiplayer replays:
Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)
MPR / SPR are prevented from being named temp_mpr / temp_spr
VR:
Updated OpenVR to version 1.10.30
Improved timing of obtaining view each frame
New "Antialiasing" option to select 4x or 8x multisampling
New "Resolution adjustment" slider (also known as supersampling)
Names over cars could fade differently in each eye in Pimax headset
Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard
FIX: Head tracking / mirrors wrong if car leaned with horizon lock
FIX: Free view FOV was wrong after entering VR in free view
FIX: Names above cars looked wrong in Pimax headsets
FIX: Some trees looked wrong in Pimax headsets
Skin downloads:
Faster skin downloads when joining server (and auto updater)
Slightly faster skin downloads when driver joins race in-game
FIX: Skin downloading could get stuck after a large header
MPR debug commands:
/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing
Views:
Horizon lock now has a strength slider option
View filter time maximum value increased to 1 second
Improved key control (4/5/6/7) of free view field of view
Three screens are now assumed when aspect ratio is 4:1 (was 3:1)
Free view mode minimum field of view reduced from 10 to 2 degrees
FIX: Filtered view went wrong with low filter time + replay speedup
Graphics:
Car shadows now use anisotropic filtering to reduce shimmering
Increased distance for car subobjects to become invisible
Controls:
Gearshift debounce setting now applies to all controller buttons
Mouse X and Y sensitivity (in Axes tab) lower limit reduced to 0.5
FIX: Rare manual shift at high speed to 1st/rev during auto shift
Force Feedback:
New settings are available under Axes / FF in Options - Controls
FF Steps maximum value is now 10000 (the maximum in DirectInput)
FF Rate is now controlled by a user setting (25 / 50 / 100 Hz)
More telemetry data for OutSim:
Enable by setting the OutSim Opts value in cfg.txt
All data options can be switched on with the value ff
The new data is documented in a header file OutSimPack.h
Misc:
When LFS is set to close the reason is logged to deb.log file
Added a little more logging about D3D initialisation to deb.log
CAR.lfs scripts are reliably run when user car is spawned or reset
FIX: Memory leak related to threads (most often for skin download)
FIX: Replays from old Westhill before 2015 now marked as obsolete
FIX: Driver names ending with a lead byte could corrupt text
FIX: Issues with driver names ending with caret character
INSTALLATION:
A FULL version of LFS 0.6U must already be installed
To install the PATCH using the SELF EXTRACTING ARCHIVE:
1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way
NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.6U25
DOWNLOADS:
IF YOU ALREADY HAVE 0.6U:
PATCH 0.6U TO 0.6U25 (SELF EXTRACTING ARCHIVE)
www.lfs.net/file_lfs.php?name=LFS_PATCH_6U_TO_6U25.exe (1.8 MB)
FOR HOSTING ONLY:
DEDICATED HOST 0.6U25 (non-graphical version for hosting only):
www.lfs.net/file_lfs.php?name=LFS_S3_DCON_6U25.zip (1.8 MB)
THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM
PLEASE TEST BEFORE YOU POST
THIS PATCH IS NOT COMPATIBLE WITH VERSION U
Hello Racers,
Here is a new test patch: 0.6U25
The changes are listed below.
0.6U25 is NOT COMPATIBLE with 0.6U
- You can NOT connect online with 0.6U
- You CAN play replays from 0.6U
Please back up or rename your LFS.exe from version U so you can revert to it if necessary.
Changes from 0.6U23 to 0.6U25: COMPATIBLE WITH U23
Steering:
Road cars now have 900 degrees steering range with default setup
XF and UF GTR have 540 degrees steering range with default setup
Updated and fixed steering animations to cover new steering range
Removed option "Move view with animation" which had little effect
FIX for new bug: Steering wheel could turn too far with some setups
FIX for new bug: Switching setups while driver visible could crash
Training:
FIX: AI changed to low fuel load if overtaking lesson restarted
FIX: AI skill / admin commands no longer processed during training
FIX: Training lesson did not end if replay saving was interrupted
FIX: Refuelling depended on refuelling allowed in single player
FIX: Logo was visible under title during lesson replay
Misc:
Removed debug message "Replay name : temp_mpr"
Saving replay name now shown beside option in Options - Game
Blocked messages remain blocked when returning from game to lobby
Command /block [0/1/2] : block user messages (like the minus key)
InSim:
IS_RES: TTime in qualifying now indicates time in session
IS_RES: PLID is now zero if the player has left the race
OutSim:
OutSim packet is documented in docs\OutSimPack.txt
Added steering torque as additional field in new OutSim
All data options can be switched on with OutSim Opts 1ff
Translations:
More updated translations. Thank you very much, translators.
Changes from 0.6U16 to 0.6U23: NEW INCOMPATIBLE VERSION
Multiplayer prediction:
Position packet now includes contact patch offset for each tyre
Wear and temperature packet is more frequent and more accurate
Pit stops:
Command /canrefuel (no/yes) to set refuelling allowed in pit stops
Damage repair not required when changing tyre pressure or compound
New ALTERNATE setup configuration for the five GTR cars:
Selecting the new config in XRR/FZR/FXR decreases tyre width a bit
With alternate config, narrower tyres may be selected (adds offset)
Also ROAD_SUPER, ROAD_NORMAL, HYBRID, KNOBBLY tyres may be selected
High "Maximum Lock" is possible in XRR/FZR with narrower wheels
XR GTR in ALTERNATE config has H-pattern shifter
Tyre choices and steering lock:
XFR and UFR maximum steering lock increased to 30 degrees
LX4 and LX6 maximum steering lock increased to 45 degrees
Single seater racing cars can now use ROAD_SUPER tyres
Steering wheel turn amount changes with maximum lock
New handling for 'CAR.lfs' and 'shift_type.lfs' scripts:
LFS runs 'road.lfs' / 'sequential.lfs' / 'paddle.lfs' directly
(previously these scripts were called from a CAR.lfs script)
This is done after loading a car and immediately before CAR.lfs
Commands to run these scripts from another script are ignored
Controls:
Handbrake strength is now separately adjustable
Graphics:
Avoid upward lighting related to ground colour in internal views
InSim:
Config byte added to IS_NPL packet indicates setup configuration
IS_CPP Pos is now relative to "Centre view" not the user setting
IS_NPL RWAdj / FWAdj indicate rear / front tyre width reduction
New bytes set if /showfuel=yes: IS_NPL Fuel / IS_PIT FuelAdd
IS_SPX and IS_LAP new byte Fuel200 indicates fuel remaining
Interface:
Tyre size displayed in Tyres tab in Garage
Brakes / TC tab in garage separated into two columns (e.g. FZ50)
FIX: Heat in garage car's tyres was not updated when tyre changed
Virtual steering gauge hidden if live settings or pit instructions
New fuel options can be filtered and are visible on selected host
When alternative config is selected F12 display shows tyre size
/press and /shift commands now support 'minus' as parameter
minus key (block messages) now works in free view mode
Misc:
Maximum number of layout objects increased to 2400
You can now add up to 32 local drivers (real + ai) in multiplayer
Restored code preventing 2 cars joining autocross within 3 seconds
FIX: Wrong warning "Road tyres on rallycross track" in hotlapping
Translation update for help.txt:
host_cars - max is now 32
guest_cars - max is now 32
max_packs - max is now 12
mip_bias - default settings now -0.5 / -1.0 / -1.5 / -2.0
Translations:
Many updated translations. Thank you, translators.
Changes from 0.6U to 0.6U16: FINAL VERSION COMPATIBLE WITH 0.6U
Interface:
Pit speed limit is shown when car speed is below 2/3 of limit
Yellow and blue flags now alternate with RCM or penalty message
Prevented auto-repeat on block message and light switching keys
Command /spectv no - prevent selecting TV camera on spectate
Momentary flick to rear view after SHIFT+R is now avoided
Avoided downshift after pressing SHIFT+X to exit free view
In fact any 'key held' function after SHIFT+key is prevented
F12 pit instructions:
Pressure change with new tyre no longer counts as SETUP CHANGES
A new 'cancel' option beside the 'setup changes requested' line
Settings that will be adjusted are now shown in light red colour
FIX: rear tyre pressure was limited by front tyre pressure limits
FIX: symmetric pressure/camber request remained after pit stop
Multiplayer:
Maximum packets per second (/pps) has been increased to 12
Rolling resistance included in catch-up phase of prediction
Reduced steering glitch each time a position packet is received
Position packets are sent more frequently in response to steering
Command /showfuel (no/yes) allows remote car fuel load to be seen
More accurate transmission of fuel load from local to remote car
Most admin commands with parameter omitted report current value
Easier to set up LAN race: local IP address is shown on host screen
You can enter the local network computer name instead of IP address
FIX: Remote cars with worn tread could wrongly get a puncture
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Stop-go penalty caused car to get stuck in custom pit stop
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin
InSim:
IS_CPP FOV can now be used in-car but not smoothed (0 = no change)
InSim NLP / MCI minimum time interval reduced to 10 ms (was 40 ms)
FIX: It was possible to miss IS_PSF packet after taking over car
FIX: STime in IS_PSF packet was wrong after car was taken over
FIX: Free view roll is now reported in InSim IS_CPP packet
CPU usage display:
In Graphics or Misc options (in-game) click car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set
Support for live multiplayer replays:
Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)
MPR / SPR are prevented from being named temp_mpr / temp_spr
VR:
Updated OpenVR to version 1.10.30
Improved timing of obtaining view each frame
New "Antialiasing" option to select 4x or 8x multisampling
New "Resolution adjustment" slider (also known as supersampling)
Names over cars could fade differently in each eye in Pimax headset
Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard
FIX: Head tracking / mirrors wrong if car leaned with horizon lock
FIX: Free view FOV was wrong after entering VR in free view
FIX: Names above cars looked wrong in Pimax headsets
FIX: Some trees looked wrong in Pimax headsets
Skin downloads:
Faster skin downloads when joining server (and auto updater)
Slightly faster skin downloads when driver joins race in-game
FIX: Skin downloading could get stuck after a large header
MPR debug commands:
/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing
Views:
Horizon lock now has a strength slider option
View filter time maximum value increased to 1 second
Improved key control (4/5/6/7) of free view field of view
Three screens are now assumed when aspect ratio is 4:1 (was 3:1)
Free view mode minimum field of view reduced from 10 to 2 degrees
FIX: Filtered view went wrong with low filter time + replay speedup
Graphics:
Car shadows now use anisotropic filtering to reduce shimmering
Increased distance for car subobjects to become invisible
Controls:
Gearshift debounce setting now applies to all controller buttons
Mouse X and Y sensitivity (in Axes tab) lower limit reduced to 0.5
FIX: Rare manual shift at high speed to 1st/rev during auto shift
Force Feedback:
New settings are available under Axes / FF in Options - Controls
FF Steps maximum value is now 10000 (the maximum in DirectInput)
FF Rate is now controlled by a user setting (25 / 50 / 100 Hz)
More telemetry data for OutSim:
Enable by setting the OutSim Opts value in cfg.txt
All data options can be switched on with the value ff
The new data is documented in a header file OutSimPack.h
Misc:
When LFS is set to close the reason is logged to deb.log file
Added a little more logging about D3D initialisation to deb.log
CAR.lfs scripts are reliably run when user car is spawned or reset
FIX: Memory leak related to threads (most often for skin download)
FIX: Replays from old Westhill before 2015 now marked as obsolete
FIX: Driver names ending with a lead byte could corrupt text
FIX: Issues with driver names ending with caret character
INSTALLATION:
A FULL version of LFS 0.6U must already be installed
To install the PATCH using the SELF EXTRACTING ARCHIVE:
1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way
NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.6U25
DOWNLOADS:
IF YOU ALREADY HAVE 0.6U:
PATCH 0.6U TO 0.6U25 (SELF EXTRACTING ARCHIVE)
www.lfs.net/file_lfs.php?name=LFS_PATCH_6U_TO_6U25.exe (1.8 MB)
FOR HOSTING ONLY:
DEDICATED HOST 0.6U25 (non-graphical version for hosting only):
www.lfs.net/file_lfs.php?name=LFS_S3_DCON_6U25.zip (1.8 MB)
Last edited by Scawen, .
Thanks for the testing and reports.
Yes. Sleep is done deliberately by LFS if you limit the frame rate or if "Sleep every frame" is set. It calls a function "Sleep(x)" which gives up x milliseconds to the operating system before continuing to process LFS code. It tries to do just the right amount of Sleep each frame to get down to the target frame rate.
"Flip" is a another kind of waiting time when we are waiting for D3D to finish and present the finished frame. One way to see that is if you use SHIFT+F11 (full screen borderless window) with vertical sync enabled.
I just noticed that if you use SHIFT+F10 (full screen exclusive mode) then all the extra CPU seems to be in "Draw" rather than "Flip" so I'll have a look why that is different from SHIFT+F11.
About your question "why would 31 AI with you cost less less cpu for physics than when alone". That should not be the case. More AI drivers should always use more CPU time for Phys. By the way, the CPU usage for the actual 'AI' is also included in "Phys" and Audio is also included there. But these are very small compared with the actual physics.
Yes. Sleep is done deliberately by LFS if you limit the frame rate or if "Sleep every frame" is set. It calls a function "Sleep(x)" which gives up x milliseconds to the operating system before continuing to process LFS code. It tries to do just the right amount of Sleep each frame to get down to the target frame rate.
"Flip" is a another kind of waiting time when we are waiting for D3D to finish and present the finished frame. One way to see that is if you use SHIFT+F11 (full screen borderless window) with vertical sync enabled.
I just noticed that if you use SHIFT+F10 (full screen exclusive mode) then all the extra CPU seems to be in "Draw" rather than "Flip" so I'll have a look why that is different from SHIFT+F11.
About your question "why would 31 AI with you cost less less cpu for physics than when alone". That should not be the case. More AI drivers should always use more CPU time for Phys. By the way, the CPU usage for the actual 'AI' is also included in "Phys" and Audio is also included there. But these are very small compared with the actual physics.
Last edited by Scawen, .
I've added this to my notes file for the compatible patch.
Thanks for the tests.
That FZR bug is one of the things I fixed yesterday, linked to by MandulAA above.
Thanks but I don't want to tackle that, as there is bug potential and complication there. Actually I'm just trying to stay sane while trying to get the compatible fixes done so I can get back to the incompatible fixes so I can release version V so I can get back to the development version and try to finish the graphics so I can get back to the tyre physics.
Thanks, got it and reproduced locally too.
Another similar bug can be reproduced with temperature. If you get the tyres very close to 200 (around 196 or so) then wheelspin a little (not exceeding 200 locally) the remote cars will get a puncture until the next wear packet arrives.
Yesterday I increased the accuracy of the transmitted fuel load as that became quite obviously inaccurate with the /showfuel option.
Car state (excluding damage) is covered by wear packets and position packets. The wear packet is for slower changing things, including fuel load, tyre temperatures and tread thickness. These changing values are worked out in physics on the remote cars but updated around every 10 seconds by a wear packet to keep them close to the local car. The position packet is of course for rapidly changing values.
In my tests I've included more in the position packet. As mentioned before, the initial tyre deflection which can stop some slight wandering of the car in the split second after the position packet arrives. In the next day or two I'll try including some of the tyre temperature data in the position packet to see if it makes much of a difference. Conceptually the tyre temperatures are somewhere between the slow changing and fast changing values. So maybe they would be better placed in the position packet rather than the wear packet. Although that's not quite such a no-brainer as you might imagine, because they are worked out physically in the remote instance anyway and they would cause quite an increase in the size of position packets. Anyway we'll see what the tests show.
Yesterday I was going through the other thread and seeing what other compatible changes I could get done. So there will be at least one more compatible patch before the incompatible ones.
Another similar bug can be reproduced with temperature. If you get the tyres very close to 200 (around 196 or so) then wheelspin a little (not exceeding 200 locally) the remote cars will get a puncture until the next wear packet arrives.
Yesterday I increased the accuracy of the transmitted fuel load as that became quite obviously inaccurate with the /showfuel option.
Car state (excluding damage) is covered by wear packets and position packets. The wear packet is for slower changing things, including fuel load, tyre temperatures and tread thickness. These changing values are worked out in physics on the remote cars but updated around every 10 seconds by a wear packet to keep them close to the local car. The position packet is of course for rapidly changing values.
In my tests I've included more in the position packet. As mentioned before, the initial tyre deflection which can stop some slight wandering of the car in the split second after the position packet arrives. In the next day or two I'll try including some of the tyre temperature data in the position packet to see if it makes much of a difference. Conceptually the tyre temperatures are somewhere between the slow changing and fast changing values. So maybe they would be better placed in the position packet rather than the wear packet. Although that's not quite such a no-brainer as you might imagine, because they are worked out physically in the remote instance anyway and they would cause quite an increase in the size of position packets. Anyway we'll see what the tests show.
Yesterday I was going through the other thread and seeing what other compatible changes I could get done. So there will be at least one more compatible patch before the incompatible ones.
AI on server would be good but our current DCon can't possibly do that, as it only has a very cut-down version of the tracks, not including the physical surfaces. It doesn't need them because it doesn't run physics. It is already possible with a full version of LFS running as the server but that requires a user name. A full version can run in 'dedicated' mode but currently runs in the same way as DCon. I think that option could be made to run physics but it's really beyond the scope of this minor update.
I only started this process to allow a wider range of settings. It's turned into a multiplayer prediction + various other things but I still want to get this done ASAP because there is a lot still to do in the development version.
No, the packet sending rate due to speed limiter was only related to packets.
The space bar for VR click is not customisable and I don't have any plans to do so. This code was designed so that space bar when typing no longer interferes with VR click, for people with a VR headset.
I don't know why you have lags but I don't think it's related to this test patch. If it is to do with graphics card limitations (memory swapping) you could try lower texture resolution. Otherwise lags could be caused by other programs running on your computer.
No tyre and lock changes for the GTR cars yet, because that would make the version incompatible with the current one. As soon as I release the incompatible patch, then half the community will be on the official version and half will be on the incompatible new version, so the online experience becomes thinly spread. That's why it makes sense to first release any changes that do not make the version incompatible. Then they can be tested while I continue with the other incompatible changes.
For example, some of the changes I have been working on, involve additional data in the pospacket. I don't want to release one incompatible version then another one that is incompatible with that one, so we have all these U versions that can't connect online.
I'm trying to make the transmitted car state a better representation of the remote car, so that at least when inputs haven't changed much, the car should continue near the correct path, until the next packet arrives. A good example is BF1 at oval. The predicted remote car car be around half a car's width from the real car even when the controller inputs remain constant. I'm trying to reduce that error by looking at things, mainly in the tyre physics.
I've tested improving the initial start state of prediction including tyre deflection in the position packet. This improved something but not enough. I can also notice difference in the MPR when rewinding to different points. Some of this difference seems to be inaccuracy in the tyre temperatures and I've found that the currently transmitted tyre temperatures are not accurate enough and I plan to try sending a more accurate version in the position packets and see if that solves the predicted car's cornering inaccuracy.
For example, some of the changes I have been working on, involve additional data in the pospacket. I don't want to release one incompatible version then another one that is incompatible with that one, so we have all these U versions that can't connect online.
I'm trying to make the transmitted car state a better representation of the remote car, so that at least when inputs haven't changed much, the car should continue near the correct path, until the next packet arrives. A good example is BF1 at oval. The predicted remote car car be around half a car's width from the real car even when the controller inputs remain constant. I'm trying to reduce that error by looking at things, mainly in the tyre physics.
I've tested improving the initial start state of prediction including tyre deflection in the position packet. This improved something but not enough. I can also notice difference in the MPR when rewinding to different points. Some of this difference seems to be inaccuracy in the tyre temperatures and I've found that the currently transmitted tyre temperatures are not accurate enough and I plan to try sending a more accurate version in the position packets and see if that solves the predicted car's cornering inaccuracy.
Test Patch U14 is now available.
I've been working on things to improve the prediction but they are mainly incompatible, so not included in this test patch.
This patch contains some compatible updates while I continue trying to improve the prediction system.
Changes from 0.6U13 to 0.6U14:
Multiplayer:
Command /showfuel (no/yes) allows remote car fuel load to be seen
Most admin commands with parameter omitted report current value
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin
MPR debug commands:
/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing
CPU usage display:
In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set
Support for live multiplayer replays:
Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)
VR:
Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard
Misc:
Increased distance for car subobjects to become invisible
FIX: Free view roll is now reported in InSim IS_CPP packet
https://www.lfs.net/forum/thread/93185
I've been working on things to improve the prediction but they are mainly incompatible, so not included in this test patch.
This patch contains some compatible updates while I continue trying to improve the prediction system.
Changes from 0.6U13 to 0.6U14:
Multiplayer:
Command /showfuel (no/yes) allows remote car fuel load to be seen
Most admin commands with parameter omitted report current value
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin
MPR debug commands:
/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing
CPU usage display:
In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set
Support for live multiplayer replays:
Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)
VR:
Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard
Misc:
Increased distance for car subobjects to become invisible
FIX: Free view roll is now reported in InSim IS_CPP packet
https://www.lfs.net/forum/thread/93185
U14 is now available.
I've been working on things to improve the prediction but they are mainly incompatible, so not included in this test patch.
This patch contains some compatible updates while I continue trying to improve the prediction system.
Changes from 0.6U13 to 0.6U14:
Multiplayer:
Command /showfuel (no/yes) allows remote car fuel load to be seen
Most admin commands with parameter omitted report current value
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin
MPR debug commands:
/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing
CPU usage display:
In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set
Support for live multiplayer replays:
Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)
VR:
Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard
Misc:
Increased distance for car subobjects to become invisible
FIX: Free view roll is now reported in InSim IS_CPP packet
https://www.lfs.net/forum/thread/93185
I've been working on things to improve the prediction but they are mainly incompatible, so not included in this test patch.
This patch contains some compatible updates while I continue trying to improve the prediction system.
Changes from 0.6U13 to 0.6U14:
Multiplayer:
Command /showfuel (no/yes) allows remote car fuel load to be seen
Most admin commands with parameter omitted report current value
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin
MPR debug commands:
/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing
CPU usage display:
In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set
Support for live multiplayer replays:
Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)
VR:
Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard
Misc:
Increased distance for car subobjects to become invisible
FIX: Free view roll is now reported in InSim IS_CPP packet
https://www.lfs.net/forum/thread/93185
Thank you all for these results and observations.
It's hard to know how the CPU usage is really being affected by the prediction. I will look and see if I can add a CPU usage timer that can display CPU usage for Physics and Prediction separately. If I could make this visible on screen at the side, then we could get more of an idea how badly Turn One mayhem is affected by increased packet rate in conjunction with high ping.
The other thing is a prediction issue that seems worst with the BF1. I don't think it's anything unique about the BF1 - it's probably just the most extreme example. I get the feeling that it is not only related to speed. I think it may be something to do with tyre deflection. Suspension deflection is included in the position packet but lateral tyre deflection is not. So I think for the first frame of prediction, forces on the car are too small and it takes a couple of updates to build up the tyre forces. It's only a theory. Unfortunately it would need a larger position packet and that can't be done in a compatible version but I'll have a look. We want to do an incompatible version anyway but we're a few days from that as there are still compatible updates to do. Anyway I can test locally at first.
I think we also need an option to watch MPRs without the steering smoothing, so it's a better representation of what we see online. Don't know if I could add a bad ping simulation to it as well.
That's a good observation. For some reason which I can't remember, the program does an estimate of when the next packet will arrive. U13 uses the U13 next packet time calculation so that explains why the U12 ones move too quickly then stop. I'm not sure why it was easier to do it that way rather than using a real packet time.
It's hard to know how the CPU usage is really being affected by the prediction. I will look and see if I can add a CPU usage timer that can display CPU usage for Physics and Prediction separately. If I could make this visible on screen at the side, then we could get more of an idea how badly Turn One mayhem is affected by increased packet rate in conjunction with high ping.
The other thing is a prediction issue that seems worst with the BF1. I don't think it's anything unique about the BF1 - it's probably just the most extreme example. I get the feeling that it is not only related to speed. I think it may be something to do with tyre deflection. Suspension deflection is included in the position packet but lateral tyre deflection is not. So I think for the first frame of prediction, forces on the car are too small and it takes a couple of updates to build up the tyre forces. It's only a theory. Unfortunately it would need a larger position packet and that can't be done in a compatible version but I'll have a look. We want to do an incompatible version anyway but we're a few days from that as there are still compatible updates to do. Anyway I can test locally at first.
I think we also need an option to watch MPRs without the steering smoothing, so it's a better representation of what we see online. Don't know if I could add a bad ping simulation to it as well.
That's a good observation. For some reason which I can't remember, the program does an estimate of when the next packet will arrive. U13 uses the U13 next packet time calculation so that explains why the U12 ones move too quickly then stop. I'm not sure why it was easier to do it that way rather than using a real packet time.
No, that would cause an enormous increase in server bandwidth and intolerable CPU usage from the extrapolation (prediction) of the position of remote cars. In the case where the remote player has a high ping, the CPU usage can become quite bad because, every time a packet is received, LFS must run the full physics from when the packet was sent, up to the current time. That could be 100ms, so 10 full physics updates and if that was 12 times per second that would be 120 physics updates per second and this would exceed even the normal physics calculations.
I ask people to consider turn one situations when a lot of cars are close together and there is a lot of physics usage and the cars are drawn at high resolution and the frame rate drops. I am fully aware of this problem and I am always trying to avoid it.
Along with this huge cost, there would also be only tiny benefits, from sending more packets when the previous packet already provides a good prediction.
There's no point in using a sledgehammer to crack a nut.
This is why the code tries to send new position packets when the previous packet can no longer be considered to provide a good prediction of the car's location. This happens faster when there have been changes to the input provided by the user.
When you are at higher speeds, you move the steering much smaller amounts. Before today's version, that would be interpreted as very little change to the input. But actually at high speeds your car moves across the road much more for a smaller steering input, that is why the steering-related packet frequency is now increased with speed.
EDIT: I don't claim this is the end of the job. I had some changes today that made sense and are moderate but noticeable enough, in my opinion, to be put out there for testing. It's safe and I want to play safe for now. This is a minor update for the existing public version and I need to be on this for as little time as possible.
Last edited by Scawen, .
I think, because of how the physics system works, the road cars just flip in this case and actually this could spoil the fun of the road car racing.
That is too much of a change in the current system. The changes we are discussing are really just about a few changes of limits, with no serious coding that I don't have time for in the old version at the moment.
All I know is that in some drift series they have used tyretools tweak software to allow these changes in the FZR and XRR for drifting. I haven't done any testing at all. I don't want to start trying to code new tyres. The aim here is only to allow what people are already doing but without the need to use memory modifying software.
Thanks for the feedback.
I was wondering about this often requested change. As usual I fear it may make things worse. I believe it can help when all players are near the server, with minimal lag. In this case it can bring similar benefits to using a high pps on a LAN. The problem I have with it is that the really bad lagging you see is usually from players with high latency (time lag to the server).
Higher pps cannot help with this. Such players, if sending twice as many packets per second, will not appear any better to the other players and will still be all over the place. Only now they will consume more CPU on the other players' computers because of the catch-up physics done on each position update.
So the problem is that more packets per second cannot possibly solve the worst problem and could make it worse. Turn 1 slowdowns could become a slide show of carnage.
I feel it's a bit like having a broken cylinder head gasket and increasing the turbo boost to try to get some more power to compensate.
But I can see that it could be worth a test. Maybe I can even run a local multiplayer test here using a remote server to get an initial feel for it before trying it in public.
Good question, I'll need to ask Victor about this.
Other comments - thanks for the feedback. I'm reading and thinking...
I was wondering about this often requested change. As usual I fear it may make things worse. I believe it can help when all players are near the server, with minimal lag. In this case it can bring similar benefits to using a high pps on a LAN. The problem I have with it is that the really bad lagging you see is usually from players with high latency (time lag to the server).
Higher pps cannot help with this. Such players, if sending twice as many packets per second, will not appear any better to the other players and will still be all over the place. Only now they will consume more CPU on the other players' computers because of the catch-up physics done on each position update.
So the problem is that more packets per second cannot possibly solve the worst problem and could make it worse. Turn 1 slowdowns could become a slide show of carnage.
I feel it's a bit like having a broken cylinder head gasket and increasing the turbo boost to try to get some more power to compensate.
But I can see that it could be worth a test. Maybe I can even run a local multiplayer test here using a remote server to get an initial feel for it before trying it in public.
Good question, I'll need to ask Victor about this.
Other comments - thanks for the feedback. I'm reading and thinking...
Progress Report, December 2020
Hello Racers,
Since the September update we have kept working hard. Eric has continued with South City, which is now a very open town area with many connecting roads. There are car parks, squares, back streets and new roads. It has taken longer than any of us expected because of the size of the area and amount of detail. My work has also taken many turns, supporting the new open city area as described in previous reports. Eric will now be starting on Fern Bay although there are still things to be finished at South City and Kyoto. I decided to present this progress report as a cut down list of updates from a few development versions since September. It gives a little insight into the process without going into too much detail about many other minor changes that there are in each version. Be warned, although cut down it's still a list of technical changes! It may be best to scroll down and look at the screenshots.
23 Oct - Lighting updates
More accurate baked lighting render for artificial lights. Drawn at higher resolution which allows more accurate results from small, bright lights in the middle distance, but with changes that allow it to run faster. Other track editor improvements. Some changes so that the apparent brightness of lights corresponds exactly with their actual lighting effect. Improved automatic exposure quality by analysing a larger texture in the compute shader.
30 Oct - Turbine updates
Wind turbines now use static vertex buffers, similar to the way a car is drawn. This allows higher resolution turbine models. The turbine code was generalised to allow 3D clock hands for city buildings.
02 Nov - Editor updates
More editor updates to allow easier positioning and alignment of objects.
13 Nov - Updates for sections
Physics enabled for the triangles on sections. Sections are the cross-sectional objects between the segments which are used for most physical surfaces in LFS (e.g. road, fences, walls). Some sections have their own surfaces (e.g. at the end of a wall) but previously they were non-physical. Editor updates to allow easier selection of objects. Slight changes to ensure that triangles on some types of connected objects are in exactly the same place, to avoid light bleeding through cracks.
20 Nov - Various editor improvements and fixes
Doubled the speed of the offline occlusion render by use of batched rendering. Enabled lights on turbines and clocks. Shader optimisation, using 4x3 matrices instead of 4x4 where possible.
18 Dec - Updates for collision with unmovable objects
Updates to the physics of unmovable objects (e.g. buildings, grandstands, smaller objects). Previously, unmovable objects used the same system as as movable objects. Now they have a more compact mesh which saves memory and CPU usage. They are now stored in the same map square system as the sections and segments. The map square system has been upgraded, to reduce the CPU time for detecting nearby objects. A discontinuity in the trunk physics calculation has been removed.
A new visualisation for the track editor shows the physical world clearly, including the physics meshes and trunk objects. Objects now have a 'surface type' that was previously only available for segment surfaces. More surface types have been added, such as rubber (tyres and some barrier linings), wood (several fences) and plastic (various barrier signs and temporary barriers). An intermediate scrape sound effect has been added for wood and plastic, avoiding the soft impact sound and the metallic scrape. The calculation for the stereo effect of the scrape sound has been improved. The colour of dust kicked up by tyres is now either white or beige depending on the surface, instead of taking on the average colour of the surface.
Eric has sent some screenshots of the latest version of South City. We hope you like the pictures.
Remember to check out the LFS calendar for racing events and follow us on Twitter.
Have a good holiday!
Since the September update we have kept working hard. Eric has continued with South City, which is now a very open town area with many connecting roads. There are car parks, squares, back streets and new roads. It has taken longer than any of us expected because of the size of the area and amount of detail. My work has also taken many turns, supporting the new open city area as described in previous reports. Eric will now be starting on Fern Bay although there are still things to be finished at South City and Kyoto. I decided to present this progress report as a cut down list of updates from a few development versions since September. It gives a little insight into the process without going into too much detail about many other minor changes that there are in each version. Be warned, although cut down it's still a list of technical changes! It may be best to scroll down and look at the screenshots.
23 Oct - Lighting updates
More accurate baked lighting render for artificial lights. Drawn at higher resolution which allows more accurate results from small, bright lights in the middle distance, but with changes that allow it to run faster. Other track editor improvements. Some changes so that the apparent brightness of lights corresponds exactly with their actual lighting effect. Improved automatic exposure quality by analysing a larger texture in the compute shader.
30 Oct - Turbine updates
Wind turbines now use static vertex buffers, similar to the way a car is drawn. This allows higher resolution turbine models. The turbine code was generalised to allow 3D clock hands for city buildings.
02 Nov - Editor updates
More editor updates to allow easier positioning and alignment of objects.
13 Nov - Updates for sections
Physics enabled for the triangles on sections. Sections are the cross-sectional objects between the segments which are used for most physical surfaces in LFS (e.g. road, fences, walls). Some sections have their own surfaces (e.g. at the end of a wall) but previously they were non-physical. Editor updates to allow easier selection of objects. Slight changes to ensure that triangles on some types of connected objects are in exactly the same place, to avoid light bleeding through cracks.
20 Nov - Various editor improvements and fixes
Doubled the speed of the offline occlusion render by use of batched rendering. Enabled lights on turbines and clocks. Shader optimisation, using 4x3 matrices instead of 4x4 where possible.
18 Dec - Updates for collision with unmovable objects
Updates to the physics of unmovable objects (e.g. buildings, grandstands, smaller objects). Previously, unmovable objects used the same system as as movable objects. Now they have a more compact mesh which saves memory and CPU usage. They are now stored in the same map square system as the sections and segments. The map square system has been upgraded, to reduce the CPU time for detecting nearby objects. A discontinuity in the trunk physics calculation has been removed.
A new visualisation for the track editor shows the physical world clearly, including the physics meshes and trunk objects. Objects now have a 'surface type' that was previously only available for segment surfaces. More surface types have been added, such as rubber (tyres and some barrier linings), wood (several fences) and plastic (various barrier signs and temporary barriers). An intermediate scrape sound effect has been added for wood and plastic, avoiding the soft impact sound and the metallic scrape. The calculation for the stereo effect of the scrape sound has been improved. The colour of dust kicked up by tyres is now either white or beige depending on the surface, instead of taking on the average colour of the surface.
Eric has sent some screenshots of the latest version of South City. We hope you like the pictures.
Remember to check out the LFS calendar for racing events and follow us on Twitter.
Have a good holiday!
Thanks for the feedback!
I decided to keep it after hearing that it is in use. I did copy, paste and simplify of the code that deals with recent impacts (the code that tries to reduce one collision event that happens over several physics frames, into a single output and avoids packet spam if there are multiple contacts with the same object in a short time). The newly added system is actually simpler (internally) because it is only concerned with local cars vs unmovable objects. It did no harm to add a few functions that work with the new style of unmovable objects.
In theory it should be easy to avoid any confusion by filtering on one bit in the OBHFlags field of the IS_OBH packet. The OBH_CAN_MOVE bit is set on all movable objects.
I think there are only 3 cases reported:
Movable, layout object - OBH_CAN_MOVE and OBH_LAYOUT are set
Movable, non-layout object - OBH_CAN_MOVE is set / OBH_LAYOUT *not* set
Unmovable, layout object (as discussed here) - OBH_CAN_MOVE is *not* set / OBH_LAYOUT is set
Unmovable, non-layout objects were always excluded because there were problems e.g. packet spam when a single seater car went around a corner with the new 3D kerb objects and a part of the body was scraping those objects.
I decided to keep it after hearing that it is in use. I did copy, paste and simplify of the code that deals with recent impacts (the code that tries to reduce one collision event that happens over several physics frames, into a single output and avoids packet spam if there are multiple contacts with the same object in a short time). The newly added system is actually simpler (internally) because it is only concerned with local cars vs unmovable objects. It did no harm to add a few functions that work with the new style of unmovable objects.
In theory it should be easy to avoid any confusion by filtering on one bit in the OBHFlags field of the IS_OBH packet. The OBH_CAN_MOVE bit is set on all movable objects.
I think there are only 3 cases reported:
Movable, layout object - OBH_CAN_MOVE and OBH_LAYOUT are set
Movable, non-layout object - OBH_CAN_MOVE is set / OBH_LAYOUT *not* set
Unmovable, layout object (as discussed here) - OBH_CAN_MOVE is *not* set / OBH_LAYOUT is set
Unmovable, non-layout objects were always excluded because there were problems e.g. packet spam when a single seater car went around a corner with the new 3D kerb objects and a part of the body was scraping those objects.
Hello programmers,
I've come across this again in the code and think I should ask you again now that the current system has been around for years.
I've been updating the collision detection of non-movable objects. There are so many objects around now, it has become quite inefficient to use the old system which uses the storage system of a movable physics object even for unmovable objects. I'm now using a much more compressed data structure for unmovable objects, that uses less memory and CPU.
But now that the movable and unmovable objects use a different type of data structure, it has become harder to support the reporting of contacts with unmovable objects.
I'm wondering if it is reasonable to stop reporting collisions with unmovable layout objects now. The way I'm thinking of this, the unmovable layout objects would be treated just the same as default non-layout objects that Eric has placed.
Movable objects would continue to be reported as before.
I've come across this again in the code and think I should ask you again now that the current system has been around for years.
I've been updating the collision detection of non-movable objects. There are so many objects around now, it has become quite inefficient to use the old system which uses the storage system of a movable physics object even for unmovable objects. I'm now using a much more compressed data structure for unmovable objects, that uses less memory and CPU.
But now that the movable and unmovable objects use a different type of data structure, it has become harder to support the reporting of contacts with unmovable objects.
I'm wondering if it is reasonable to stop reporting collisions with unmovable layout objects now. The way I'm thinking of this, the unmovable layout objects would be treated just the same as default non-layout objects that Eric has placed.
Movable objects would continue to be reported as before.
I don't have time to get into tyre physics at the moment but had some thoughts on it after Eeekie's post.
I think there are some competing effects when the throttle is applied.
1) As Eeekie described, the rear wheels become more loaded, lengthening the contact patch and so requiring less slip angle for a given lateral force. And conversely the front wheels become less loaded, get a shorter contact patch and require more slip angle for a given lateral force. From this point of view the car might take a wider line without any steering adjustment.
2) But there is another effect and that is that a wheel which has a longitudinal force applied, will produce less lateral force for a given slip angle. So from this point of view, a rear wheel drive car with more throttle applied (and no change in steering input) will follow a tighter line because the rear wheels will require a wider slip angle for a given force.
3) There are also other possible competing effects, such as the change in toe and camber due to suspension deflection, and the effect of a limited slip differential.
Now, I definitely may be wrong but I imagine number (2) above to be the dominant effect. I think that is how it is in my car but it would be hard to test unless I can find a skid pad. It may well be that a different effect is dominant in different cars, due to the different mass distributions and other design features. As I apply the throttle there is a whole range of slip angles before the point when the whole contact patch is skidding. Now I'm really not a crazy driver at all these days and don't drive much anyway but there are times when I can accelerate pretty hard out of a roundabout without any danger to myself or others. I can apply a lot of power without actually going sideways and it feels to me like it gets closer to oversteer through that process. It feels very planted and poised as I apply more power. A good part of my mind is focussed on the rear wheels, remembering I used to be a motorcyclist and am very aware of going over the limit. It's a feeling of confidence though and there is a certain joy to it. I believe I get this same feeling in the new physics of LFS, but in the old LFS there are some slight changes of line that don't seem to correspond with reality.
I think there are some competing effects when the throttle is applied.
1) As Eeekie described, the rear wheels become more loaded, lengthening the contact patch and so requiring less slip angle for a given lateral force. And conversely the front wheels become less loaded, get a shorter contact patch and require more slip angle for a given lateral force. From this point of view the car might take a wider line without any steering adjustment.
2) But there is another effect and that is that a wheel which has a longitudinal force applied, will produce less lateral force for a given slip angle. So from this point of view, a rear wheel drive car with more throttle applied (and no change in steering input) will follow a tighter line because the rear wheels will require a wider slip angle for a given force.
3) There are also other possible competing effects, such as the change in toe and camber due to suspension deflection, and the effect of a limited slip differential.
Now, I definitely may be wrong but I imagine number (2) above to be the dominant effect. I think that is how it is in my car but it would be hard to test unless I can find a skid pad. It may well be that a different effect is dominant in different cars, due to the different mass distributions and other design features. As I apply the throttle there is a whole range of slip angles before the point when the whole contact patch is skidding. Now I'm really not a crazy driver at all these days and don't drive much anyway but there are times when I can accelerate pretty hard out of a roundabout without any danger to myself or others. I can apply a lot of power without actually going sideways and it feels to me like it gets closer to oversteer through that process. It feels very planted and poised as I apply more power. A good part of my mind is focussed on the rear wheels, remembering I used to be a motorcyclist and am very aware of going over the limit. It's a feeling of confidence though and there is a certain joy to it. I believe I get this same feeling in the new physics of LFS, but in the old LFS there are some slight changes of line that don't seem to correspond with reality.
FGED GREDG RDFGDR GSFDG